Improve decoding full-sized images in RCTImageLoader
#54127
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
meta-cla
bot
added
the
CLA Signed
facebook-github-bot
added
p: Software Mansion
tsapeta
force-pushed
the
faster-full-size-image-decoding
branch
from
45896bc to
cf8b5f2
Compare
facebook-github-bot
added
the
Shared with Meta
cipolleschi
approved these changes
Oct 16, 2025
|
@cipolleschi has imported this pull request. If you are a Meta employee, you can view this in D84835416. |
cipolleschi
pushed a commit
to cipolleschi/react-native
that referenced
this pull request
Oct 17, 2025
Summary: In Expo, someone reported (expo/expo#40158) that `expo-image-manipulator` causes memory crashes when processing large images (> 30MB). Image manipulator uses `RCTImageLoader` to load and decode images. As opposed to the Image component, it always requests for images in full size. For large images it may crash at `CGImageSourceCreateThumbnailAtIndex` which in the provided repro slowly increases memory usage until it finally crashes after a few seconds of running. I figured out that not including the `kCGImageSourceThumbnailMaxPixelSize` option works much better, but using `CGImageSourceCreateImageAtIndex` instead of `CGImageSourceCreateThumbnailAtIndex` works even better – it's faster and consumes less memory during decoding. This is more or less what `SDWebImage` library does, see [`SDImageIOAnimatedCoder`](https://github.com/SDWebImage/SDWebImage/blob/master/SDWebImage/Core/SDImageIOAnimatedCoder.m#L488-L509). With the proposed changes, it's still crashing but only for the largest image (64MB), other images (40MB and 50MB) are now working fine. Obviously, it cannot be fixed entirely and it's not recommended to load such big images without downscaling them. ## Changelog: [IOS] [CHANGED] - Use `CGImageSourceCreateImageAtIndex` instead of `CGImageSourceCreateThumbnailAtIndex` to decode full-sized images Test Plan: I've tested the examples of the `Image` component in RNTester as well as the repro provided in expo/expo#40158 Reviewed By: javache Differential Revision: D84835416 Pulled By: cipolleschi
|
@cipolleschi merged this pull request in be4fcda. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
In Expo, someone reported (expo/expo#40158) that
expo-image-manipulatorcauses memory crashes when processing large images (> 30MB).Image manipulator uses
RCTImageLoaderto load and decode images. As opposed to the Image component, it always requests for images in full size. For large images it may crash atCGImageSourceCreateThumbnailAtIndexwhich in the provided repro slowly increases memory usage until it finally crashes after a few seconds of running.I figured out that not including the
kCGImageSourceThumbnailMaxPixelSizeoption works much better, but usingCGImageSourceCreateImageAtIndexinstead ofCGImageSourceCreateThumbnailAtIndexworks even better – it's faster and consumes less memory during decoding. This is more or less whatSDWebImagelibrary does, seeSDImageIOAnimatedCoder.With the proposed changes, it's still crashing but only for the largest image (64MB), other images (40MB and 50MB) are now working fine. Obviously, it cannot be fixed entirely and it's not recommended to load such big images without downscaling them.
Changelog:
[IOS] [CHANGED] - Use
CGImageSourceCreateImageAtIndexinstead ofCGImageSourceCreateThumbnailAtIndexto decode full-sized imagesTest Plan:
I've tested the examples of the
Imagecomponent in RNTester as well as the repro provided in expo/expo#40158